Skip to content

fix: toBeDisabled now also evaluates disabled prop when element is Text #1802

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 3 commits into from
Jul 30, 2025
Merged

fix: toBeDisabled now also evaluates disabled prop when element is Text #1802

merged 3 commits into from
Jul 30, 2025

Conversation

rarenatoe
Copy link
Contributor

@rarenatoe rarenatoe commented Jul 24, 2025 •
edited
Loading

Summary

Resolves #1801 by ensuring Text components with the disabled prop are correctly identified as disabled by computeAriaDisabled.

Previously, computeAriaDisabled didn't check for the disabled prop on Text elements, causing queries like getByRole('text', { disabled: true }) to fail. The change adds a check to return true when isHostText(element) and props.disabled are both true, aligning react-native-testing-library's behavior with expected accessibility states.

Test plan

New unit tests have been added for computeAriaDisabled to verify this change. These tests cover:

  1. Text component with disabled={true}: Asserts computeAriaDisabled returns true.

  2. Text component without disabled prop or disabled={false}: Asserts computeAriaDisabled returns false.

  3. Existing TextInput behavior: Ensures non-editable TextInput components are still correctly identified as disabled.

  4. aria-disabled and accessibilityState.disabled props: Verifies these existing checks continue to function.

The new computeAriaDisabled tests should pass, demonstrating correct handling of the disabled prop on Text components.

@codecov Codecov
Copy link

codecov bot commented Jul 30, 2025 •
edited
Loading

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.33%. Comparing base (cc1e249) to head (d168214).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files 
@@            Coverage Diff             @@
##             main    #1802      +/-   ##
==========================================
+ Coverage   95.25%   95.33%   +0.08%     
==========================================
  Files          94       94              
  Lines        5247     5253       +6     
  Branches      569      575       +6     
==========================================
+ Hits         4998     5008      +10     
+ Misses        249      245       -4

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@mdjastrzebski mdjastrzebski merged commit 5407f70 into callstack:main Jul 30, 2025
7 checks passed
@rarenatoe
Copy link
Contributor Author

@mdjastrzebski Would it be possible to merge this into v12 too? It'd be a huge help, as our team is currently skipping v13. We're doing this to avoid react-test-renderer's deprecated act warnings. Since v12 doesn't have concurrent rendering, it saves us from needing to use act everywhere when migrating to v13.

@mdjastrzebski
Copy link
Member

@rarenatoe You should be able to use v13 without serious effort.

  1. Afaik act warning should be related do your react-test-renderer/react version rather than RNTL.
  2. You can disable concurrent rendering with configure({ concurrentRoot: false }) in your jest-setup.ts.

Which version of React & React Native are you on?

@rarenatoe
Copy link
Contributor Author

rarenatoe commented Jul 30, 2025 •
edited
Loading

I am on react 18.3.1 and react-native 0.77.3
I'd prefer not to set concurrentRoot: false because otherwise it's something that is later forgotten forever and never migrated. If there is a new standard, it's better to align to it the moment one ups the package version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

toBeDisabled() matcher behavior with Text component and onPress/disabled props
2 participants
@rarenatoe @mdjastrzebski